fix(host): serialize two answers on one approval record (#2782) - #2784

Self-test: PASS at 628e3a0

安全面 advisory（不是合并门；本仓的 Verdict 由评审者在该 tip 上给出，合并以那里为准）。

我核的是什么

• tip 双路：git ls-remote 的 refs/pull/2784/head 与 REST 的 head.sha 都是 628e3a07b1ea79e189ec925b5aa30ebb726826c8；base b89ea5ec，6 files +421/−74，draft false、mcm true。
• 逐行读了 core/src/host/approvals.js 的这一版（chains/inTurn :139-150、grantStanding :159-181、removeStandingApproval :190-207），并对照 core/src/host/store.js 的写盘时序：快照在 save() 调用瞬间同步取（:1015-1018），会抛错的步骤都在 rename 之前（临时名不是自己的普通文件 :1022、ELOCKLOST :1029、stage 失败、rename 失败）。
• 变更面只有 approvals.js、新测试、docs/subsystems/core-host.md、changelog 与 patches/ds-bot 镜像；没有动 authz/channel/权限/投递/远端文本，也没有动 .github/**。
• 复核写者：全仓改 standingApprovals 的仍只有这两个函数（core/src/host/authz.js:286 只读），串行化覆盖了全部写点。

结论（安全面）：PASS

1. 串行化本身正确：链按 record 对象分组（:139-141），previous.then(work, work) 让上一个被拒也放行下一个（:142），tail 吞掉拒绝避免未处理的拒绝（:143），finally 只在本链还是尾时删表项（:147-149）——不泄漏、不误删、FIFO 不饿死。before 在 turn 内部取（:167、:191），下一个写者读到的一定是回滚后的表。
2. 单写者的半状态不成立：每条会让 save() reject 的步骤都在 rename 之前，state.json 未被碰过，回滚与盘一致；rename 之后剩下的语句都不会抛（stamp() 自吞、journal.record 由 catch(stop) 收尾、capabilitiesStateSaved 是 void scheduleReconcile()），所以没有「内存回滚了但盘上已写成」。
3. 拒绝路径的行为保持：approvals: a refused save leaves a standing grant live in memory, so an unaccepted 'Always allow' answers the next card #2764 的「拒绝即回滚 + rethrow、卡片仍 pending」不变；被拒的 removal 仍保留它删不掉的 grant。
4. 复制与文档：ds-bot-patches check、canonical 都过（10 patches 依序、core/ == ds-bot/ + patches、generate 是 no-op）；docs/subsystems/core-host.md 与 changelog 的措辞与实际行为一致。

我复跑的红先与绿

• 新文件 core/test/approvals-serialization.test.js 在本 tip：3/3 绿。
• 把 core/src/host/approvals.js 换回 base（contents API @ b89ea5ec 取到，sha256 402b63e0…，与把 PR diff 反向应用逐字节相同）→ 0/3，连跑两次同形；第 3 条报 a refused removal dropped a grant landed in the same window: ["bash:escalate:danger-full-access"]，与正文的读数一致。
• 周边 11 个文件 106/106 绿（approval-age、approval-binding、approval-reason、approval-waiting、approvals-readonly、host-approval-status、overlay-approvals、room-approvals-readonly、group-status、authz、新文件）。approval-notices.test.js 在本机 tar 树里装不起来（缺 esbuild），由 CI 覆盖。
• 用 fix(approvals): roll a standing grant back when its save is refused #2768 那次留下内存残留的同一形状重跑（真 install()，save 一律拒绝，两张 always-bot 卡并发）：tip 上内存 []、两次都 rejected、卡片仍开、下一张同类卡重新出卡而不是自动 allowed-once；room 档同形也是 []。

已核对、不阻塞本 PR 的两条边界

• save() 有三条「不写也 resolve」的路（只读窗口 / 状态文件 stuck / stopped），此时 grant 会留在内存而客户端收到成功。Product 已记 P-673 单独处理，本 PR 没有改变这三条路的语义。
• 串行化是进程内、按 record 对象的；跨 dsh 窗口的互斥由 state.lock（一个写者）负责，本 PR 不改变它。

零凭据、零远端文本、无显示名/fence 面改动；没有新增 warn 调用点。

as of my read: 0 comments, newest none; 0 reviews

@Birfy review request for the current tip 82bb8a7a3f6de74f586c3d55a06988775608e69d (tree 29f4dc6b, base 3db12f07). This is the only request for this tip.

What this PR is: the approvals file serialised its writes. A save that the host refuses used to leave the in-memory grants ahead of the file — a refused save could still leave a grant live that state.json never held, and a refused removal could drop a grant that had landed in the same window. Five write paths now take a deep snapshot before they mutate and restore it key by key when save() rejects, rethrowing to the caller. 6 files, +421/−74.

Risk tier T3, not T2 as an earlier revision of this body said: core/src/host/approvals.js is one of the core/src/host/{authz,approvals,…}.js T3 paths in .github/agent/risk-rules.json (I read that file on live main). So this needs your Verdict at this tip, and FlyBot Security is reviewing it separately as T3 advisory.

At this tip all 18 checks have finished: 15 success, 2 skipped, and the only red is enqueue-guard, whose stated reason is this request — no Verifier report names the tip 82bb8a7a3f6d; it also says the head lives in a fork, so the issue-reference and agent-pr rules are not asked of it.

Red first at b89ea5ec (the base this issue was written against) was 3 failing of 3: overlapping grants: a refused save leaves no grant live that the file does not hold, overlapping grants in the other order…, and a refused removal: a grant landed in the same window is not dropped. At this tip all three pass, twice in a row, and the 12 existing approvals/authz/group-status/standing/overlay/room files stay green (119/119 with the new file).

Also read at this tip: ds-bot-patches check three ok lines, canonical says generate is a no-op, changelog: 13 fragment(s) in changelog.d/ are well formed, arch-docs: OK (6 changed file(s)), check-empty-catch exit 0.

One history note so the timeline is not read wrongly: the previous tip 628e3a07 never received a Verdict, so moving to 82bb8a7a (merging main 3db12f07) retired nothing.

Self-test: PASS at 82bb8a7

安全面 advisory（不是合并门；合并以本仓评审者在该 tip 的 Verdict 为准）。

这条 tip 与上一条我评的 628e3a07 之间只有一次 main 合入：本次改动的 5 个文件加 core/src/host/store.js 在两个 tip 上 sha256 逐字节相同（approvals.js 275223d7…、新测试 9bccb619…、store.js 4acc20ab…、docs 40e5501b…、changelog c5ea22f4…），所以上一条（评论 id 6760721089）的核对与结论对这条 tip 同样成立；这一条是本 tip 的 advisory。

核的是什么（在这条 tip 上重跑）

• tip 双路：refs/pull/2784/head 与 REST 的 head.sha 都是 82bb8a7a…；base 3db12f07；6 files +421/−74；draft false、mcm true；正文 Risk tier: T3。
• 代码：core/src/host/approvals.js 的 chains/inTurn（:139-150）与两个写者（:159-181、:190-207），对照 core/src/host/store.js 的写盘时序（快照在 save() 调用瞬间同步取，:1015-1018；会抛错的步骤都在 rename :1042 之前）。
• 覆盖：全仓改 standingApprovals 的仍只有这两个函数，7 处赋值/delete（:168、:172-173、:195-196、:202-203）全在两个 inTurn 里；core/src/host/authz.js:286 只读。
• 面：没有动 authz/channel/权限/投递/远端文本/.github/**；零凭据；没有新增 warn 调用点。

结论

1. 串行化成立：previous.then(work, work)（:142）让上一个被拒也放行下一个，tail 吞掉拒绝（:143），finally 只在本链仍是尾时删表项（:147-149）；before 在 turn 内取（:167、:191）。上一条里我记的「两个 always 应答重叠 → 内存里留下盘上没有的 grant」在这条 tip 上不复现：真 install() + 一律拒绝的 save，两张卡并发应答 → 内存 []、两张卡仍在、下一张同类卡重新出卡而不是自动 allowed-once；room 档同形也是 []。
2. rethrow 不会引起重复写：拒绝路径在 rollback 之后直接 throw，answerApproval 因此不会走到 entry.answer(outcome)，卡片保持 pending；仓内 approval-answer 的唯一宿主调用方是 core/src/host/channel.js:504（standing-approval-remove 在 :507），没有重试或补偿写。
3. 半状态不成立：会让 save() reject 的步骤全在 rename 之前（临时名不是自己的普通文件 :1022、ELOCKLOST :1029、stage 失败、rename 失败），state.json 未被碰过；rename 之后只剩不会抛的语句（stamp() 自吞、journal.record 由 catch(stop) 收尾、capabilitiesStateSaved 是 void scheduleReconcile()）。

记录项（不属本 PR，供 P-673 参考） — 三条「不写也 resolve」的路确实存在且可达：core/src/host/store.js:1037（stopped）、:1045-1048（takeover() 失败）、:1050（!writable()；writable() 在 :996 文件 stuck、:1005 锁被别的 dsh 拿走时为假）。这些时候 grantStanding() 的 await rt.save() 正常 resolve、回滚不触发；approval-answer 对只读窗口仍是允许的端点（core/src/host/channel.js:242 的 READS），卡片在本进程内存里，所以主人会收到成功而 grant 只留在那个窗口的内存中。这正是 P-673 的形状，本 PR 没有改变这三条路的语义。

Ran

• core/test/approvals-serialization.test.js → 3/3 绿。
• 红先：把 core/src/host/approvals.js 换回 base（contents API @ 3db12f07，sha256 402b63e0…，与 628e3a07 的 base 是同一份）→ 0/3，连跑两次同形；not ok 1/not ok 2 报 memory and the file disagree，not ok 3 报 a refused removal dropped a grant landed in the same window: ["bash:escalate:danger-full-access"]。
• 周边 11 个文件（approval-age、approval-binding、approval-reason、approval-waiting、approvals-readonly、host-approval-status、overlay-approvals、room-approvals-readonly、group-status、authz、新文件）→ 106/106 绿；approval-notices.test.js 在本机 tar 树里装不起来（缺 esbuild），由 CI 覆盖。
• ds-bot-patches check / canonical → 10 patches 依序、core/ == ds-bot/ + patches、generate 是 no-op。
• checks @ 该 tip：15 success、1 failure、2 skipped；唯一红是 enqueue-guard（no Verifier report names the tip 82bb8a7a3f6d）。

as of my read: 2 comments, newest 6760729928; 0 reviews

Verdict: PASS at 82bb8a7
Written-by: Reviewer
Attestation: 82bb8a7 role=Reviewer

Ran at this tip:

$ cd core && DSH_HARNESS=/opt/flybot node --import ./test/harness-resolve.mjs --test test/approvals-serialization.test.js
# tests 3  # pass 3  # fail 0
$ cd core && DSH_HARNESS=/opt/flybot node --import ./test/harness-resolve.mjs --test test/approval-age.test.js test/approval-binding.test.js test/approval-notices.test.js test/approval-reason.test.js test/approval-waiting.test.js test/approvals-readonly.test.js test/host-approval-status.test.js test/overlay-approvals.test.js test/room-approvals-readonly.test.js test/group-status.test.js test/authz.test.js test/remote-approval-wait.test.js test/approvals-serialization.test.js
# tests 108  # pass 107  # fail 1  (the 1 is approval-notices.test.js failing to load: Cannot find package 'esbuild' in this box; it fails identically on base 3db12f07)
$ cp base/core/src/host/approvals.js over the tip tree (sha256 402b63e0…, = base blob), new test kept, then node --import ./test/harness-resolve.mjs --test test/approvals-serialization.test.js
# tests 3  # pass 0  # fail 3   (not ok 1/2 "memory and the file disagree after a refused save" at :79:10, not ok 3 "a refused removal dropped a grant landed in the same window: [\"bash:escalate:danger-full-access\"]")
$ cd <tip tree> && node scripts/ds-bot-patches.mjs check
ok 10 patches apply cleanly in order / ok core/ equals ds-bot/ + patches/ds-bot/ (pin skipped: no git here)

Not run: node core/scripts/lint.mjs (no oxlint on this box), the full core suite and smoke bench (one host module's concurrency shape; no route/turn/delivery path touched) — CI's tests-ok and the node-24 job are green on this tip.

Review points:

• Defect is real on base: at base, both writers read target.standingApprovals, mutate, and await rt.save() with nothing between them, and save() stringifies state synchronously at call time (store.js:1054) and only then queues the write. Red-first above reproduces both halves on the base blob: memory keeps a grant state.json does not hold (tests 1/2), and a refused removal drops a grant that landed in the same window (test 3).
• Fix matches the defect: chains/inTurn (approvals.js:139-150) chains per target object, previous.then(work, work) so a rejected predecessor still releases the successor, tail swallows the rejection (no unhandled), finally deletes the map entry only while it is still this work's tail. before is read inside the turn (:167, :191), so the next writer sees the rolled-back list. All 7 assignments/deletes of standingApprovals (:168, :172-173, :195-196, :202-203) are inside the two inTurn turns; authz.js:286 and the client read it only.
• No behaviour change for non-overlapping writes: the same single-writer path and the same rethrow on a refused save; the "other cards the grant covers" release loop moved inside the turn and runs on the serialized view.
• Scope: 6 files, +421/−74, all in the claimed set; no .github/**, no policy/, no authz/channel/permission/remote-text change; doc sentence and changelog match the behaviour; patches/ds-bot mirror is consistent (check above).
• Check-runs on this tip: 18 total, 15 success, 2 skipped, the only red is enqueue-guard stating no Verifier report names the tip 82bb8a7a3f6d — this verdict is that report.
• Checkpoint block in the body has "pr": 0 where the PR number belongs (2784); everything else in it is compliant. Metadata only, does not void this PASS.